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PCT/NO98/00348 



A SYSTEM AND METHOD FOR IMPLEMENTING AN AUCTION ON A 

COMPUTER NETWORK 

FIELD OF THE INVENTION 
5 The present invention relates to auction systems and more particularly to 

systems and methods for implementing an auction system on a network, e.g. a 
computer network or a TV network, or by means of an automaton. 

BACKGROUND OF THE INVENTION 
10 The disclosures of the following documents are incorporated herein by 

reference: 

U.S. patents 5,282,633 granted Feb. 1, 1994 to Boylan et al.; 5,083,271 
granted Jan.21, 1992 to Thacher at al.; 5,630,757 granted May 20, 1997 to Gagin 
et al.; 4,927,156 granted May 22, 1990 to Breslow et al.; 5,009,429 granted April 

15 23, 1991 to Auxier; 4,637,614 granted October 18, 1985 to Gibbon et al.; 
4,261,575 granted April 14, 1981 to Corely et al.; 5,559,312 granted September 
24, 1996 to Lucero; 4,922,522 granted May 1, 1990 to Scanlon; 4,998,199 
granted March 5, 1991 to Tashiro et al.; 5,038,022 granted August 6, 1991 to 
Lucero; 5,159,549 granted October 27, 1992. to Hallman et al.; 5083,272 granted 

20 Jan.21, 1992 to Walker et al.; and 5,083,271 granted January 21, 1992 to 
Thacher et al.; 

PCT applications: WO 95/31061 filed May 5, 1995 by Catapult 
Entertainment, Inc.; WO 93/23125 filed May 14, 1993 by Codemasters limited; 
and WO 93/22017 filed April 30,1993; and 
25 European patent application 0 405 776 A2 published January 2, 1 991 . 

SUMMARY OF THE INVENTION 

In a first aspect, the present invention is a computerized auction system 
which includes the following features: auction means for processing bids 
30 communicated from participants of an auction, communicating receipts of the bids 
and status details of the auction to the participants, and determining a winner of 
the participants based on the bids received and communicating the winner to the 



WO 99/27476 PCT/NO98/00348 

2 

participants; bidder means for distinctly communicating to the auction means 
distinct the bids from respective the participants and processing the receipts of the 
bids and the status details of the auction communicated from the auction means; 
network means for providing communication transmission paths between the 
5 auction means and the bidder means, information communicated across the 
network means between the auction means and the bidder means being under at 
least one of a first transport protocol and a second transport protocol, the first 
transport protocol being more reliable than the second transport protocol with 
respect to insuring that data representative of the information arrives at one of the 

10 auction means and the bidder means, the second transport protocol being faster 
than the first transport protocol with respect to time elapsed for the data to be sent 
across the network means and received by one of the auction means and the 
bidder means, wherein risks associated with the information communicated under 
the second transport protocol include loss of the data during transmission across 

15 the network means, arrival of the data at one of the auction means and the bidder 
means in an order different from a temporal order in which the data were sent 
from respective one of the bidder means and the auction means, and duplicates of 
the data arriving at one of the auction means and the bidder means, the risks 
being an aspect of the auction in respect of the determining the winner of the 

20 participants. 

Preferably, the bids are communicated from the bidder means to the 
auction means under the second transport protocol, and the auction means 
includes auctioneer means for processing the bids communicated from the bidder 
means and communicating the receipts of the bids and the status details of the 

25 auction to the bidder means, the auctioneer means communicating with the bidder 
means under the second transport protocol. The auction system preferably further 
includes administrative means for processing accounts of the participants and 
processing information related to the auction apart from information 
communicated between the auctioneer means and the bidder means, and the 

30 auction means preferably includes auction support means for prompting the 
auction means to begin the auction, the auction support means communicating 
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with the administrative means on a secure communications channel over a 
transmission path that is one of outside the network means and through the 
network means. 

In a preferred embodiment of the auction system, the network means 
5 includes at least one of a telephone network, a public mail network, a telefax 
network, a local area network, and the Internet, the first transport protocol includes 
a Transport Control. Protocol/Internet Protocol (TCP/IP), and the second transport 
protocol includes a User Datagram Protocol (UDP). 

In a preferred embodiment of the auction system, the bidder means 
10 communicate with the auctioneer means under auction protocols layered on top of 
the first or second transport protocols, and these auction protocols may comprise 
auction administration and bidding protocols. Further, the bidding protocols may 
preferably include parameters comprising a value for each of said bids, counts of 
messages received by said auctioneer means from said bidder means for each of 
15 said participants, notions of time of said auction by each of said bidder means, 
identification of winner of said participants, time when said auction started, time 
when said auction is over and a current one of said bids becomes a final bid, 
number of said bids communicated to said auctioneer means at any one time, 
number of bids each of said participants has left, how long one of said bids must 
20 survive to win in said auction, and number of said participants. 

In a second aspect, the present invention relates to a computer network 
auction system server which includes means for processing bids communicated 
from participants of an auction across a computer network, 

means for communicating information across the computer network to the 
25 participants in response to the bids communicated from the participants, 

means for determining a winner of the participants based on the bids 
received across the computer network; 

means for communicating across the computer network the winner to the 
participants; 

30 means for a first transport protocol under which the means for 

communicating information and the winner are carried out; and 
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means for a second transport protocol under which the bids are 
communicated across the computer network from the participants, 
communications under the first transport protocol being more reliable than under 
the second transport protocol with respect to the communications arriving at their 
5 destination, communications under the second transport protocol being faster than 
under the first transport protocol in respect of time from initially transmitting the 
communications to arrival of the communications at an intended destination, 
wherein risks associated with communicating under the second transport protocol 
include loss of the bids during transmission across the computer network, arrival 
10 of the bids from different ones of the participants being in an order different from a 
temporal order in which the bids were sent from respective ones of the 
participants, and duplicates of at least one of the bids arriving at an intended 
destination, the risks being an aspect of the auction in respect of the means for 
determining the winner of the participants. 
15 The computer network auction server of the mentioned preferably 

comprises administrative means for processing accounts of the participants, and 
the administrative means further comprises means for processing content in a 
form of World Wide Web pages communicated to and from the bidder means. 

Preferably the first transport protocol comprises a Transport Control 
20 Protocol/Internet Protocol (TCP/IP), and the second transport protocol comprises 
a User Datagram Protocol (UDP). 

A third aspect of the present invention relates to a method for implementing 
an auction system on a communication network, which method comprises 

communicating bids by input computer equipment of respective participants 
25 of an auction across a network to auction computer equipment; 

processing received the bids by the auction computer equipment; 

providing by the auction computer equipment across the network receipts 
of the bids to the input computer equipment; 

determining by the auction computer equipment a winner of the participants 
30 based on the bids received from the input computer equipment; and 

communicating by the auction computer equipment to the input computer 
equipment the winner of the participants; 
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providing first and second transport protocols under which communications 
between the auction computer equipment and the input computer equipment are 
carried out, the first transport protocol being more reliable than the second 
transport protocol with respect to the communications arriving at an intended 
5 destination, the second transport protocol being faster than the first transport 

protocol with respect to time elapsed for the communications to be sent across the 
network and received by at least one of the input computer equipment and the 
auction computer equipment, wherein risks associated with the communications 
under the second transport protocol include loss of the communications in the 

10 network, arrival of the communications at one of the auction computer equipment 
and the input computer equipment in an order different from a temporal order in 
which the communications were sent from respective one of the input computer 
equipment and auction computer equipment, and duplicates of the 
communications arriving at one of the auction computer equipment and the input 

15 computer equipment, the risks being an aspect of the auction in respect of the 
determining the winner of the participants. 

Preferably the method in accordance with the third aspect of the invention 
comprises processing accounts of said participants and storing results of the 
auction. The network may comprise a public mail network, a telephone network, a 

20 telefax network, a radio network, a TV network or a computer network. 

The network utilized may comprise the Internet, the first transport protocol 
then comprising a Transport Control Protocol/Internet Protocol (TCP/IP), and the 
second transport protocol may comprise a User Datagram Protocol (UDP). 

Preferably the method in accordance with the third aspect of the invention 

25 includes carrying out communications related to the bids between the auction 
computer equipment and the input computer equipment under auction protocols 
layered on top of the first or second transport protocols. The auction protocols 
may comprise auction administration and bidding protocols. Preferably the bidding 
protocols include parameters comprising a value for each of the bids, counts of 

30 messages received by the auctioneer means from the bidder means for each of 
the participants, notions of time of the auction by each of the bidder means, 
identification of winner of the participants, time when the auction started, time 
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when the auction is over and a current one of the bids becomes a final bid, 
number of the bids communicated to the auctioneer means at any one time, 
number of bids each of the participants has left, how long one of the bids must 
survive to win in the auction, and number of the participants. 
5 In a fourth aspect, the present invention concerns a method for 

implementing an auction on a computer network server, which method comprises 

processing bids communicated from participants of an auction across a 
computer network, 

communicating information across the computer network to the 
10 participants in response to the bids communicated from the participants, 

determining a winner of the participants based on the bids received 
across the computer network; 

communicating across the computer network the winner to the 
participants; 

15 communicating across the computer network under one of a first transport 

protocol and a second transport protocol, arrival of communications at an intended 
destination being more reliable but slower under the first transport protocol than 
under the second transport protocol, risk of communications being lost, delayed 
and duplicated under the second transport protocol being an aspect of the auction 

20 in respect of determining the winner of the participants. 

In a fifth aspect of the present invention there is provided an auction system 
based upon submittal of stake-supported bids from auction participants within pre- 
established time limits, the system possibly comprising a communication network 
for communication between an auctioneer and the participants, the auction system 

25 comprising 

- interface means adapted for presenting bids from the participants, 

- a detector means for detecting bids submitted from each participant, 

- a real or simulated clock situated with the auctioneer for marking the start 
and end times for an auction, recording running auction time as well as time points 

30 for bid detection in the detector means, and 

- a decision means for deciding on an auction result, the auction result being a 
function of the bid time points. 
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Preferably, the decision means is adapted to test whether a predetermined 
time period, or a time period variable according to predetermined rules, has 
passed after the last detected bid without detection of a new incoming bid, and if 
this is the case, to identify the participant with the last detected bid as an auction 
5 winner, and if this is not the case during the total auction duration, to identify the 
participant having submitted the last bid before the auction end time, as a winner. 

The interface means may be computer terminals attached to a real time 
data-transmitting communication network, possibly via modem, and the auctioneer 
then attached to the same network by means of a computer terminal in a similar 
10 manner. Further, the auctioneer clock, the detector means and the decision 

means may then be comprised in an auctioneer computer adapted to manage an 
auction in accordance with programmed auction algorithms. 

The auctioneer computer algorithms are preferably adapted to manage bids 
submitted in real time from the participants during the course of the auction. In a 
15 specific embodiment, the computer may even be adapted for possible correction 
due to transmission delay from the computer terminals of the participants. 

One of the auctioneer computer algorithms may be an algorithm for varying 
the length of the time period to "hammer down" as a function of elapsed auction 
time or as a function of the current bid submittal rate from the total of the 
20 participants. 

In order to present to each participant the running auction progress and 
activity, the participant computer terminals and also the communication network 
may be adapted for transmission of real time information from the auctioneer 
computer. 

25 In a special embodiment, the auctioneer computer algorithms may be 

adapted to manage bids submitted in a group from each participant within a fixed 
point of time, so that when this point of time has passed, the computer can 
immediately simulate the total course of the auction. 

The total number of bids during the auction may be predetermined, and the 

30 auctioneer computer algorithms are then adapted to manage bids submitted from 
each participant at the same time as the participant makes entry for the 
auction/pays the bids. 
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Alternatively, if no limit is set for the total number of bids during the auction, 
the auctioneer computer algorithms will be adapted to manage a) auction 
entry/payment of bids from each respective participant within a predetermined 
point of time, b) thereafter calculating the total auction time, i.e. the time span from 
5 start to end time, c) establishing a time limit for submittal of grouped bid times, 
from each respective participant, and (d) subsequent to reception of bids from the 
participants and expiry of the time limit, simulation of the total course of the 
auction. 

The auctioneer computer, the participant computer terminals and the 
10 communication network may further be adapted for transmission of information 
about the simulated course of the auction to each respective participant, possibly 
in the form of a screen presentation of the auction course in a real or transformed 
time scale. 

In an even further specified embodiment, the auctioneer computer may also 

15 be adapted to transmit, in accordance with special programming, side information 
to the participant computer terminals, (a) the side information being controlled 
during real time or simulated auction progress by the auctioneer clock and 
possibly by the running auction development, for initiating picture/sound 
presentation or short film of a type which is auction related, entertaining or 

20 distracting, next to or "behind"the auction information, in order to increase the 
auction attraction, and (b) the side information comprising, during phases with 
entry/payment/pre-bidding, animations containing entertainment or auction related 
information or possibly advertising. 

In an alternative embodiment of the auction system of the fifth aspect, the 

25 auctioneer computer may comprise a memory for storing a total auction course, so 
that a participant may have data concerning the auction course presented in his 
computer terminal automatically or on request after a finished auction. 

In an embodiment of the fifth aspect of the invention, which embodiment is 
directed to an auction performed by means of an automaton, at least one 

30 participant is a genuine participant and a plurality of participants is a number of 
simulated participants, the system further comprising auctioneer random 
generator means controlling the number of and bidding times for simulated 



WO 99/27476 PCT/NO98/00348 

9 

participants in accordance with predetermined random generator algorithms, the 
algorithms containing parameters adjustable so as to tune auction winning 
probability into a range that is compatible with national law. 

In a preferred embodiment of the auction system of the fifth aspect, the 
5 communication network may be devided in two parts, 

part of the communication network may be any of a public switched 
telephone network, a cellular network, a computer network and a reverse TV 
channel network, 

the interface means may be any of telephones, cellular phones, telefax 
1 0 units, computer terminals, and TV sets having two-way communication 
capabilities, 

the auctioneer may be broadcasting any of a radio program, a TV program 
and a text TV program via another part of the communication network, which other 
part is constituted by any of a public radio channel, a TV channel and a closed- 

1 5 circuit network, in which radic/TV/text TV program real time information is 
transmitted regarding auction progress. 

In a completely different embodiment of the auction system in accordance 
with the fifth aspect of the invention, the interface means are coupons to be 
completed by each participant and sent to the auctioneer, a coupon containing 

20 information about the desired bid time points for the participant in question within a 
pre-established time frame, and with a number of bids fixed according to rule and 
according to stake, the detector means is a coupon reader unit, the decision 
means is a preprogrammed computer attached to the coupon reader unit, and the 
clock is a simulated clock according to which the bids from the participants are 

25 ordered chronologically, the communication network being a public mail network, 
a telephone network, a telefax network or a computer network. 

In a sixth aspect of the invention, there is provided a method for an auction 
based upon submittal of stake-supported bids from auction participants within pre- 
established time limits, the auction comprising the steps of: 

30 presenting to an auctioneer bids from the participants via at least 

interface means, 
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detecting by auctioneer bid detector means bids submitted from any 
participant, 

using a real or simulated clock situated with the auctioneer for marking 
start and end times for the auction, and for recording running auction time as well 
5 as time points for bid detection by the auctioneer bid detector means, and 
deciding on an auction result by an auctioneer decision means, the 
auction result being a function of the bid time points. 

Preferably the auction method also comprises testing whether a 
predetermined time period, or a time period variable according to predetermined 
10 rules, has passed after the last detected bid without detection of a new incoming 
bid, and if this is the case, identifying the participant with the last detected bid as 
an auction winner, and if this is not the case during the total auction duration, 
identifying the participant having submitted the last bid before the auction end 
time, as a winner. 

15 

BRIEF DESCRIPTION OF THE DRAWINGS 

In the following a more detailed description of the invention is given, 
referring also to embodiment examples illustrated in the appended drawings, 
where 

20 fig. 1 shows schematically basic elements of a computerized auction 

system in accordance with a first aspect of the invention, 

fig. 2 shows hardware and software platform characteristics of network 

servers constituting an essential element of the computerized auction system in 

accordance with the first four aspects of the invention, 
25 fig. 3 shown hardware and software platform characteristics of network 

clients which constitute another essential element of the computerized auction 

system in accordance with the first four aspects of the invention, 

fig. 4 shows an auction system overview in accordance with the first aspect 

of the invention, 

30 fig. 5 is a flow diagram illuminating some necessary steps in a method in 

accordance with the invention, 
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fig. 6 is a communication chart showing connections between any client 
and the auctioneer game engine, 

fig. 7 is another communication chart highlighting connections between 
auctioneer servers and the closest part of the communications network, 
5 fig. 8 illustrates what happens in a real time version of an "American 

auction", 

fig. 9 illustrates what happens in an "instant" version of an "American 
auction", 

fig. 10 illustrates what happens in a "strategic/simulation" version of an 
10 "American auction", 

fig. 1 1 shows in a schematical manner all possible communication network 
connections between objects participating in an auction in accordance with the 
invention, and 

fig. 12 shows an example of a bid board display for an auction participant in 
15 a sealed bid type auction. 

DETAILED DESCRIPTION OF THE INVENTION 

Fig. 1 is a simple illustration of general features of the computerized and 
network-based auction embodiment of the invention, in which embodiment the 

20 auctioneer uses at least two network servers as shown in the left part of the 
drawing, of which one server is mainly an administrative server for processing 
participants 1 accounts and related information, while the other server processes 
bids communicated via the network from the participants, as well as 
communications to the participants regarding running auction status details. 

25 The figure further shows examples of participant PC-s and the 

communication network in general. 

Fig. 2 deals with examples of required hardware and software platforms for 
the two necessary network servers. The drawing is text-based and self- 
explanatory, and the text thereof is hereby incorporated. 

30 Fig. 3 deals with examples of required hardware and software platforms for 

participant PC-s, and the drawing textual and self-explanatory. The text is 
incorporated herein. 
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The original auction concept, at the outset being a network dependent 
invention, can easily be adapted to cover a much wider market segment, 
adaptation i.a. as follows: 

M game-boy M type machines 
5 - distributed via CD's/simulation 

automatic game machines 

advertising tools/auctioning 3 rd party company products. 
The inventor believes that this will enhance, at low cost, the value of the invention. 
The basic, underlying concept "American Auction" is a concept where 
10 strategic skills are important for winning the auction. Participating will also 
enhance the strategic (and analytic) skills over a peripd of play, improving the 
participants general strategic skills in his normal life/work situation, thus having 
major educational and competitive elements. Last, but not least, the participation 
is entertaining via the excitement of the actual auction, and the various supporting 
15 themes. 

Strategy , education and entertainment are the three most important 
attractive/selling features of the auction concept, and will (have to) be present in 
all versions of the invention. As the focus has been on these features while 
developing the Auction concept, we believe that these are present as an 
20 integrated part of the concept. 

While, however, different market segments/populations have varied focus 
on these elements, it is important to "tailor" products/themes and actual medium, 
in addition to segmentation according to stake/pot size. 

By doing this, the auction organizer will be able to cover a vast market, covering 
25 both high/low "status" markets, also competing with more traditional game 
machines, "game boy", pure entertainment games (PC and/or Internet based) etc. 

It has also become clear to the inventor, that the Auction well may be an 
excellent marketing tool for Computer/Internet related (as well as non-related) 
companies in advertising and selling their products through selling licenses and 
30 arranging auctions for these companies where their products are the auction pot. 
Such auctions may be distributed via CD (through PC magazines or otherwise), or 
via a look-up through a web browser or company home page. It is felt that this 
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idea has a major potential for being a new marketing/advertising concept, where a 
product can be prominently displayed to an attentive audience for a long period of 
time. 

The concept can be used in a number of "spin-off" products highlighting 
5 strategic, educational and/or the entertainment features and variants of same. 

1 . "Game boy" type palm-held machine where the competition is simulated by 
selected number of participants (competition), number of competing/own 
bids and a varied number of bids per participant/groups of participants. This 
flexibility will give different degrees of difficulty the same way as current 

10 "game boy" machines, but with totally different features through themes, 

strategy and entertainment value. Game pot in the form of points. 
Entertaining themes, however, simpler artistically, due to limited capacity. 

2. CD, or Internet distributed simulation auctions (with same features as the 
"game boy" version), but with a more sophisticated animation and choices, 

15 to be distributed (for CD's) via PC Magazines/Mail etc. and to be played via 

own PC. 

This product may be excellent as an enhancement of the animations of the 
original Auction concept as well as being a stand-alone product for 
entertainment as well as training for the actual Coin Auctions. 
20 These CD/lntemet distributed simulation auctions are also excellent media 

for advertising (see above). 

3. Automatic game machines/Simulation of competition. 

Same concept as 1 and 2 above, but with winning pot. Such an automaton 
auction concept would be covered by Games Legislation in many countries. 
25 The pot would be dependant on the chosen degree of difficulty. 

This product will compete directly with the current game machine market, 
and licensing to current operators should be considered. 

4. Auctions arranged for the purpose of advertising products, where 
pot/auction object is the advertising company's product/products. 

30 Distribution both via Internet and CD's. 
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First preferred embodiment of the invention: 

A system for conducting an "American Auction" across an internet 

American auction resembles an ordinary auction, where players make bids, 
and if a bid is unchallenged for some period of time the last bidder wins. However, 
5 in this auction all bids are the same "size", players pay for each bid they make, 
and the player who makes the last valid bid is the winner. 
It is referred in general to figs. 1-8. 

The auctioneer uses, or preferably is a program which handles incoming 
bids from authorized bidders. The program runs on a machine with an internet 
10 connection. The bidders must use machines with access to the same internet that 
the auctioneer is connected to. The machines must be equipped with a WWW 
browser which can down load and execute Java applets. All participants in an 
auction communicate with the same (single) auctioneer using special "auction 
protocols" layered on top of the standard Internet Protocols. 
15 Fig. 4 is an overview of an embodiment of the computerized auction system 

of the invention. First level parameters are auction rules, auction protocols, system 
capacity, performance/optimizations, auction operation and security issues. 

On a next level the auction protocols are divided into an auction 
administration protocol and a bidding protocol that are handled separately. 
20 On a next level below the performance/optimizations level, one aspect is 

the avoidance of data conversions, and another aspect is reduction of message 
traffic. 

Under the security issues there are aspects related to initialization, bidding, 
overload and result distribution. 

25 

1 . The Rules (see fig. 5) 
1.1 Preliminaries 

• there are N players 

• each player must buy at least min bids, before the auction starts 

30 • there is currently no maximum limit on the number of bids a player can 

buy 

• a player cannot buy more bids once an auction has started 
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1.2 Startup 

• Players must decide if they want to play before the auction starts. 
(Otherwise players could watch the auction, and join late without risk and 
with an added chance of winning.) 

• It should be possible to rejoin the auction after the auction has started 
(client machines will crash). 

• During demos players will be allowed to log in at any time. 



10 1.3 The Play 

• players are notified whenever a bid is made 

• whenever a player makes a bid, a clock is started 

• if timeout seconds elapse without further bids, the player who made the 
last bid is declared the winner 

15 • there is an (imposed) upper limit on the duration of a auction, probably 

between one and two hours 

• the timeout decreases as the auction grows older 

There is a chicken and egg problem at the start of the auction, when no 
one has made any bid, and there is no winner. It is possible to set the initial 

20 timeout to the entire auction duration, and reset it to a "normal" value when the 
first real bid arrives. This works well for demo purposes, but is probably not 
suitable for a real auction. Another solution is to set the initial timeout normally, 
and if no one has made a bid during the first timeout seconds, the organizer of the 
auction is the winner. A third solution is to have a "house player" who gives a 

25 single bid sometime at the start of the auction, and is quiet thereafter. The house 
player wins on behalf of the auction organizer. 

The auction needs to stop some time. Assume there are 3600 players, 
each with 10 bids available. With a timeout of 10 seconds, a worst case auction 
will last 100 hours, which is clearly not acceptable. 
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In one embodiment, the timeouts are decreased linearly as the auction 
grows older. However, the timeout cannot be allosed to approach zero, so that the 
round trip time becomes greater than the timeout. A timeout lower limit must be 
set, or one solution might be to publish a deadline for each auction. If the auction 
5 reaches the deadline without having established a winner, the Xth bid to arrive 
after the deadline becomes the winning bid. 

1.4 Payoff 

• unused bids in excess of min are returned to the players 
10 • collect penalties each player must pay for at least min bids 

• the auction organizer takes a cut (e.g. 20%) of the total income, the rest 
(the pot) is paid back to the participants (winners) 

• players who have not made any bids get nothing 

• the winner gets some fraction prize (e.g. 80%) of pot 
15 • the winner gets all his bids refunded (if possible) 

• while there are money left: the players who have made fewest bids get a 
refund of their made bids (not their penalty bids) 

• any excess (round off errors etc.) go the auction organizer. 

20 2. Auction Protocols 

The protocol may e.g. use ASCII text encoding. Each message consists of 
some number of fields, separated by blanks. The first field is a single "tag" 
character which identifies the type of the message. 

25 2.1 Auction Administration 

It is convenient to use a reliable connection for the administrative 
commands, Login and Quit. 

Referring to fig. 6, when a participant wishes to send an administrative 
command (Login or Quit), he (the client) should follow the following steps: 
30 1. open a TCP connection to Auctioneer server/Game engine (using 

the same port number as the UDP connection for bidding uses). 
2. format and write the command to the connection 
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3. read the response (or possibly "end of file") 

4. close the connection 

In fig. 6, lower part, are shown two sequential access storage media, i.e. 
one containing data regarding legitimate participants (players) and one for storing 
5 logs, both connected to the administrative network server. 

It is assumed that the administrative system distributes a client code to the 
participants, together with a "name" and (eventually) authentication information, 
encryption keys etc. 

At the start of the auction the participant must log on to the server with a 
10 Login mesage. The server (auctioneer) will reply with an Accept message or an 
Error message. 

Login = L name port 

Accept = A winner start now deadline bidsmade bids/eft timeout who serial 
15 Error=E string 

name an alphanumeric string 

port the UDP port the client whiches to use 

winner the id of the current winner 

now the auctioneer's idea of the current time 

20 start when the auction started (if start > now the auction has not started 

yet) 

deadline auctioneer's notion of time when the current bid becomes final (if 

deadline < now the auction is over) 
serial the serial number of the message this is a reply to 

25 bidsmade how many bids have been made so far (total) 
bidsleft number of bids the player has left 

who numeric id the player should use in remaining communication with 

the server 

timeout how long a bid must survive in order to win 

30 
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When a participant detects that the auction is over, he should ask for 
results by sending a Quit message. The server will reply with either a Payoff 
message, a Wait message (if the auction is not over yet), or an Error message. 



10 



Quit = Q who 

Payoff - P who result bidsmade bidspaid 
Error = E string 
Wait = W 

who numeric id 

result net amount won (or lost if negative) 
bidsmade number of bids seen by the server 
bidspaid number of bids the player must pay for 



2.2 Bidding Protocol 
15 It would be preferable to have a reliable real time communication channel 

between the auctioneer and the participant throughout the auction, but the Internet 

protocols can not provide this. 

Instead UDP is preferably used as the transport protocol for the bids. This 

means that messages can get lost, they can arrive out of order, and they may be 
20 duplicated. 

Message delays and message loss should be considered part of the 
auction, and an aspect of the auction that participants should be aware of. 

The auctioneer measures time in seconds since auction start. The 
auctioneer's notion of time is the one that counts. 
25 The participants can announce that they are still alive, and they can make 

bids. 



Bid = B bid serial who now 

bid takes the values 0 ("I am here") or 1 ("I want to make a bid") 

30 serial each participant keeps a count of how many messages he has sent, 
the first message has serial number 0 
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who each participant gets a unique (numeric) identification at auction 

start 

now the participant's notion of auction time (unused by the auctioneer so 

far) 

5 

The client program should probably send empty bids at "slightly random" 
regular intervals, perhaps something like an average of two messages per minute. 

The auctioneer sends a Receipt for every message it receives from a 
player The auctioneer broadcasts a Status message whenever he receives a new 
10 bid (and possibly at other times as well): 



Receipt = R winner start now deadline bidsmade bidsleft serial who when 
Status = S winner start now deadline bidsmade timeout max 
winner the id of the current winner 
15 now the auctioneer's notion of current time 

start when the auction started (if start > now the auction has not started 

yet) 

deadline auction time when the current bid becomes final (if deadline < now 
the auction is over) 
20 serial the serial number of the message this is a reply to 

bidsmade how many bids have been made so far (total) 
bidsleft number of bids the participant has left 
who numeric id of participant 

when the 'now 1 value of the bid this is a reply to 
25 timeout how long a bid must survive in order to win 

max number of (potentially) participating bidders (this should probably be 

the number of "active" participants, and perhaps it should only 
include participants with bids left) 



30 



For each participant, the auctioneer will keep track of the serial number last 
seen. When the auctioneer receives a bid (or an "I'm here" message), it will check 
the serial number of the new message against the saved serial number. 
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• If the new serial number is greater than the saved one, it is accepted, 
analyzed, and replied to. 

• If the new serial number is less than or equal to the saved number, it has 
arrived out or order (or it may be duplicate). The message is ignored 

5 (and not replied to). 

The client should probably compute a running estimate of the round trip 
time, and it is probably a good idea for a client to synchronize it's notion of time 
with that of the auctioneer. 

It is the auctioneer's count of the number of bids made by a participant 
10 which counts. The client should probably keep track of the last message it has got 
a receipt for, and attempt to synchronize the local count of the number of bids 
made, with that of the auctioneer. The client program should probably not prohibit 
the participant from sending more bids than the participant is supposed to. 



15 3. Capacity 

Each participating bidder should get a notification of new bids "immediately" 
when a new bid is accepted from a legitimate bidder. Such notifications ("status 
messages") are ASCII text messages, they are small (less than 100 characters), 
and the content is not secret. 
20 The time from the auctioneer gets a new bid until it can start broadcasting 

status messages is negligible compared to the time it takes to do the broadcast. 

A machine which executes the auctioneer program should have the 
capacity to send the same (small) message to N different UDP addresses in the 
course of S seconds, where N is the number of participating bidders, and S is an 
25 acceptable approximation of "immediately". 

The status message will be sent to one bidder at a time, so that the delay 
(from the auctioneer) will be 0 for the first bidder and S seconds for the last. 

The bidders will in addition experience network delay. It is hard to predict 
how much delay will be acceptable to the bidders. One might guess that a total 
30 delay of less than 1 second is more than good enough, while delays greater than 
4 seconds will be unacceptable. 
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Tests have been performed using Sun Sparcstation 20 machines running 
Solaris 2.5. It seems that these can send somewhere between 1000 and 2000 
UDP messages per second. 



5 4. Performance and Optimizations 
4.1 Avoiding Data Conversions 

Messages and logs are textual, all numbers are transmitted in decimal. This 
is good for debugging purposes, but the server will spend a fair amount of time 
converting between binary data and textual format. Either binary formats or 
10 special purpose textual routines could improve speed. 



4.2 Reducing Message Traffic 

Clients should send few "I'm here" messages. Clients will probably receive 
sufficient number of Status messages to stay reasonably updated. 
15 Sending Status messages to all clients is the main bottleneck. IP multicast 

would probably remove this bottleneck, but is unfortunately not generally 
available. 

One should try to avoid "useless" status messages, for instance by trying to 
detect if a batch of bids arrives at more or less the same time, and send a status 
20 message only when the last one has been processed. 

If the load is very high, and there is a batch of bids coming in, one could 
quietly "drop" all bids but the last (players would gain by this). 

If the load is high, try to avoid sending Receipts for non winning or empty 

bids. 

25 One could let the server send "unsolicited" receipts if it has dull periods. 

5. Running an auction 

A real auction should be handled using (at least) two web servers, see 
figs. 1, 2 and 7. 

30 In fig. 7 is shown an example of connections between the closest central 

Router in the network and the auction servers. An administration server has a two- 
way connection to the network, operating under a first transport protocol that is 
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reliable, however not necessarily very fast. This server is able to present a WWW 
menu leading to a demo, a log on possibility for a participant other types of 
information, and a credit cheque feature is also included. 

The administration server provides user names, passwords etc. for an 
5 auction server that has another type of connection to the network, i.e. a 
connection operating under a faster, but less reliable transport protocol. This fast 
connection takes care of the actual real time bidding process in which messages 
(bids) must be conveyed rapidly to the auctioneer, as well as receipts to the 
participants. 

10 A third auctioneer server has also been included in the drawing, which 

server takes care of messages that are common to all participants, and may 

operate under the first mentioned transport protocol. 

The main administrative server handles accounts, auction information and 

web pages, and should not execute on the same machine as the auctioneer. 
15 A "small" web server must execute on the same machine as the auctioneer, 

This server communicates with the main server across a secure channel, and has 

the following tasks (see also fig. 2): 

• on request send Java code to legitimate auction participants (bidders) 

• start the auction program (the auctioneer) at the correct time with the 
20 correct parameters 

• save the result of an auction (logs and payoff matrix) 

The auctioneer is preferably a normal Unix program, and can be started 
from the command line: 

• auction options 
25 The options are: 

- 1 string set log-prefix to string. As a special case, if log-prefix is not set, all 

logs go to standard output. 
- b file name of a file of legal bidders, no file implies demo mode. This file is 

currently an ASCII text file, containing one line for each legal bidder. 
30 Each line consists of at least two fields, separated with whitespace. 

The first field is the name of the bidder. The second field is the 
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maximum number of bids this bidder is allowed to make. Further 
fields are currently ignored, but are expected to contain security 
information (keys, passwords). 

- p port number of the port to use. The same port number is used for UDP 
5 and TCP. The current default is 6010, which is a fairly random 

choice. 

- s time when the auction starts. Currently two formats are accepted: +n 

starts in n seconds, or h.m starts today at h.m o'clock. Current 
default is +1 (start after 1 second). 
10 -d minutes how long the auction lasts. Current default is 20 minutes. 
- 1 seconds initial timeout (default is 20 seconds). 

-mmax default max number of bids per bidder when running demos 
(default 8). 

-D demo mode, allow anyone to log in (implied if no -b option) 

15 

The auctioneer prints a list of authorized bidders before the auction starts 
(a requirement for accounting and audit reasons). The first line identifies the 
auction, the second is a comment, and the remaining lines are one for each 
bidder. 

20 Each line contains a numeric id, the name of the bidder, and the number of 

bids he has available. 
Example: 

# ./auction (0.9) 1997/1 1/17/10.19.36 = 000879760176 castor 

# id who bids 
25 000000 . 0 

000001 Eigil 8 

000002 Tom 8 

000003 Eirik 8 

000004 Brynjulv 8 

30 
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During the auction, the auctioneer prints interesting events to a log file. 
Each line starts with a "time-stamp", which is the current auctioneer time (in 
seconds since some reference time), followed by a "serial number" within each 
second. 

5 Log lines are either Comment lines, Login lines, Quit lines, Bid lines or 

Status lines. Status lines are printed whenever a new status message is 
broadcast. 

Comment = time-stamp # comments 
1 0 Login - time-stamp L id port name addr result 
Bid = time-stamp B bid id serial time disp 
Status = time-stamp S winner left timeout total 
Quit = time-stamp Q id 



id numeric id 

1 5 winner the id of the current winner 

port which port the bidder wishes to use for status messages 

name real name of bidder 

addr internet address of bidder 

result one of "ok", "no" or "late" 

20 serial serial number of the bid 

bid 1 (real bid) or 0 (no bid) 

time bidders notion of time (unused by auctioneer) 

disp how the bid is treated 

(emptyBid/GameOver/waitABit/noneLeft/Accepted) 

25 left time left until deadline (from timestamp) 

timeout current timeout value 

total total number of bids made by all bidders so far 
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An example except: 

0879760175.00000 # ./auction (0.9) 1997/11/17/10.49.36 = 000879760176 castor 

0879760177.00000 # NOTSTARTED -* RUNNING 

0879760177.00001 S 000000 1 199 020 0 

5 0879760179.00000 L 1 43391 Eigil 156.116.2.222:43391 ok 

0879760179.00001 B 1 00001 000000 879760179.854896 accepted 
0879760179.00003 S 000001 020 020 1 
0879760180.00021 B 1 000004 000008 879760180.886145 noneLeft 

0879760238.00001 # result printed 

10 0879760238.00002 S 000002 -01 019 32 
0879760243.00000 Q 000001 

0879760249.00002 # auction over : 879760237 

After the auction is over, the auctioneer prints a result file, which consists of 
15 an initial identifying line, then a header line, followed by one line for each active 
bidder. Each line contains the bidder's numeric id, the bidder's name, the net 
result, and the number of bids made. 

Example: 

# ./auction (0.9) 1997/11/17/10.49.36 = 000879760176 castor 



20 # id who result bids 

000000 . 0 0 

000001 Eigil -8 8 

000002 Tom 17 8 

000003 Eirik -8 8 
25 000004 Brynjulv -8 8 
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6. Source Code 

# date 

Fri Nov 7 13:18:45 MET 1997 

# wc bids.c commands.c log.c main.c payoff.c player.c rungame.c util.c game.h 



1 Or 


4ft 1 

■to 1 






135 


425 


2783 


commands.c 


39 


104 


765 


log.c 


164 


650 


4813 


main.c 


113 


446 


2477 


payoff.c 


108 


426 


2732 


player.c 


200 


640 


4643 


rungame.c 


133 


439 


2954 


util.c 


128 


541 


3287 


game.h 


1157 


4152 


27706 


total 



25 



main.c 

rungame.c 

bids.c 

commands.c 

payoff.c 

player.c 

log.c 

util.c 

game.h 

clientc 



main program for the auctioneer 
actually run the auction 
handle incoming bids 

handle incoming (top) commands (logon and quit) 
implements current rules for payoff at end of auction 
read/create player data structures 
implements logging functions 
various utilities 

contains common typedefe and declarations 
a program which creates one or more clients 



7. Security Issues 
7.1 Initialization 

It is here assumed that the auctioneer program will be started by a minimal 
30 web server running on the same machine as the auctioneer. 

This minimal web server will communicate with the main administrative web 
server using SSL, and will deliver Java code to authenticated clients (participants). 
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7.2 Bidding 

During the auction the participants send Bids, and the Server sends 
Receipts and Status messages. Message loss is part of the game. 
5 Cheaters may attempt to listen to message traffic they are not entitled to 

see, they may attempt to inject false messages into the message streams, they 
may resend genuine messages, or they may push "junk bytes" into the message 
streams. 

Authentication and encryption techniques can be used to ensure the 
10 integrity of messages, at a possibly substantial cost in processing time. 

The simplest approach is to have the auctioneer share a secret key with 
each player. This key is used to encrypt and decrypt Receipts, Bids and Status 
messages. 

There does not seem to be any compelling reason to keep the content of 
15 messages secret. If this is so, it is sufficient if we use the key to attach a signature 
to each message. 

7.3 Overload 

One possible attack could run as follows: A participant decides to bid. As 
20 soon as she gets a receipt she activates one or more programs which attempt to 
block other participants from getting their bids through to the server. These 
programs could send as much junk data as possible to the auctioneer. 

A possible counter to this sort of attack is for the server to slow down the 
clock if it receives a burst of junk. 

25 

7.4 Result Distribution 

The server writes the result and the log to files, e.g. sequential files as 
shown in fig. 6. Administrative routines must ensure that these files are kept as 
long as needed, and that they are not tampered with. 

30 
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8. Further preferable features 

• The Auctioneer should minimize the number of status messages sent. 

• The Auctioneer must provide signed (or possibly encrypted) messages. 
There are public domain C implementations of MD5 which can be used 

5 as a basis for signing messages. 

• The Auctioneer must handle overload gracefully. A suitable strategy for 
this must be specified and implemented. 

• It must be possible to ensure that auctions finish in a reasonable amount 
of time. A strategy for timely termination of an auction must be specified 

10 and implemented. 



FURTHER AUCTION EMBODIMENTS 

A) " REAL TIME" - Interactive, see fig. 8. 

Fig. 8 relates to the real time embodiment of the computer network auction 
15 system. A clock symbolizes the starting time of the auction, prior to which time 

participants must have signed on and bought a predetermined number of bids. 
The "rolling film" symbolizes the running auction time period, during which 

any participant may place his successive bids at successive points of time to stop 

the "auction hammer" from falling all the way down. The rolling film may also 
20 symbolize a log of the auction progress, which log can be "replayed" at a later 

time. 

The real time auction is played interactively in "real time" starting at a fixed 
time and ending when one participant wins. (Exactly like a "normal" auction.) Bids 
are bought ahead of time, and used during the auction at participant's option. 
25 The length of the auction depends on the allowed number of participants 

and bids per participant. Theoretically, the auction may be never-ending, therefore 
it is important to limit auction time by limiting number of bids (participants and/or 
bids). Likely maximum is 2500 bids (say: 5 bids and 500 participants) 
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The auction does not start unless bidding starts. It is unlikely that anybody 
wants to be the first bidder. Therefore the auction machine has one bid which is 
used to start the bid process (1 st bid only). 

A bid wins as long as no other bids come in within a set number of 
seconds. At the outset this time period is planned set at 30 seconds. (As 
visualized by timer count-down meter ("auction hammer falling") presented on 
participants' PC screens.) 

To limit total auction time, this variable (30 seconds until winning) may be 
reduced to 20 sec. and 10 sec. a certain time into the auction, which also 
increases the intensity of the auction and the nervousness of the participants, thus 
over-proportionately reducing auction time. 

Safety/security features, how to prevent or counteract jamming. 

The net work auction must be protected from unauthorized activities from 
participants, and one should also create procedures to be followed in case of 
technical breakedown/Ioss of a significant number of participants. 

In case of a technical breakdown, i.e. the loss of contact with a certain 
number (major number) of participants, and/or the server is in an "overload" 
situation, the auction will be stopped. A random number of bids will then be 
"erased" as legitimate bids, and returned to the bidders. In this way, nobody can 
predict which bid was the last bid, in case of manipulation. After a "clean-up", i.e. 
when on-line access has been re-established, the auction restarts. 

The auctioneer shall have on-line contact with at least n% of the 
participants at any time. When this limit is crossed, the auction stops, contact must 
be re-established, and the auction then continues. 

Regarding the problem of jamming, a safety precaution for the auction, and 
a precaution against manipulation, is a function where the "java-applet" on the 
client PC continuously sends (fake) messages as an "on-line check". For an 
outsider/manipulator, these checks are impossible to distinguish from real bids, 
which complicates a possible manipulation effort. Further, traditional "fire-walls" 
will be implemented for the auction server, and the highest approved security in 
coding will be implemented. At present, a 56 bit DES-algorithm is approved for 
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commercial applications from the US. This security code compares to codes 
currently used by e.g. the Bank of Norway. 

To eliminate a bidder with a certain jamming strategy, the auction may be 
stopped in the same manner as described above, a random number of bids will be 
5 cancelled to eliminate the jamming bidder, and the game will then be restarted. 



Optional features: 

All of the three below items will have (be perceived as having) 
entertainment value for the participants and set the auction above other games: 
10 ♦ Interactivity 

• Design 

• Strategy game (log - analysis of individual strategy compared to other 
participants/winner after auction end - or alternatively during auction) 

- Interactivity 

15 The auction has full "real-time" interaction as one sees all actions of other 

participants, and your own actions are re-action to this. 

- Design 

Pure entertaining features are presented as background design visualizing 
the action of the participants via theme-stories. The story must reflect the action of 
20 the participants, i.e. also be interactive with the auction-action. The themes may 
be "auction-theme with auctioneer, gold-coin machine etc.", dragons and 
dungeons, war-game, etc., i.e. the themes may be unlimited as long as theme (or 
action within the story) may easily reflect the auction-action. 

Another feature is that a participant may choose from a range of 
25 background stories, the one to his liking, which gives him/her most excitement. 

- Strategy 

One may choose different strategies for participating in the auction. The 
(ultimate) point of the auction is to have the bid surviving for 30 seconds (or as 
long as the auction-rule specifies for a winner). 
30 Below we will try to present strategies as we see them presently, by 

indicating in a table individual participant's chances to win as affected by other 
participants' strategy: 
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Individual strategy: 




Action 


Non-Action (wait) 


Other 

participants 1 
strategy: 


Action 


Reduced chances 


Increased chances 




Non-Action 


Increased chances 


Reduced chances 




Alternative results for individual participant: 




• Winning (others 
don't bid) 

• Loosing (no more 
bids) 

• Remaining in 
auction 


• Loosing (other 
winner) 

• Surviving (others 
bid) 

• Winning (bids left 

vvhen others have 
none) 



One will see from the above table that it is important for the winning 
chances that the participant is counter-'cyclical" to the "mainstream" strategy. The 
5 strategy may have to be different for the different periods of the auction 

(beginning/middle/end), as one may see a "non action" strategy in the beginning, 
and an "action" strategy towards the end, so one should actually plan more than 
one strategy for each individual auction. 

An auction-log comparing individual participant's strategy with average 
10 participant/winner will give feedback for strategy in a next auction. This, we 

expect, will be perceived as "educationalTa learning experience", and definitely 
entertaining, even if a winning strategy for one auction may be a loosing strategy 
for the next one. 
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Lastly, the auction log may be used to define: 

1 . 2 nd /3 rd place (after winner) 

2. winner strategy 

3. optimal strategy - early/middle/late auction 
5 4. total time in winning position 

5. how many bid-rounds you have waited out ("stayed cool") 

6. how many bids given at the same time 

A limited number of participants give high winning chances compared to 
most other game types, thus giving a high attraction value. 
10 Market segmentation: 

l^ier segmentation : Participants must have access to PC or another type 
of interface equipment. 

2 nd tier segmentation : Cost of bids. (I.e. covers affluent and average 
segment based on this variable). 
15 Examples: 

Affluent: 100/1000 USD bid (total cost at 5 bids/auction 500/5000 USD auction) 
Average: 1/20 USD bid (total cost at 5 bids/auction 5/100 USD auction) 



B) SIMULATION 1 Non interactive, see fig. 9. 

20 Fig. 9 is similar to fig. 8, but relates to a "simulated auction" embodiment, 

i.e. the auctioneer computer calculates (calculator symbolized as machine in 
centre) an immediate result when bids with indicated time points have been 
received from all participants. A log is prepared at the same time, symbolized by 
the short "film roll" on the right, and the log can be fetched at any time later by the 

25 participant. 

This is the auction version for participants who want full freedom in 
choosing their own time for participation - without having to wait through the 
auction process, or a set bid-time or auction time. The beauty (from the 
organizer's point of view) of this auction is that it is an auction totally flexible as 
30 concerns fulfilling market demand, as one auction starts as soon as the previous 
is finished. 
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This simulated auction is non-interactive, with limited number of 
participants. Participants are signing on/purchasing bids, and bidding individually 
up to a flexible starting time (when the pre-set number of participants have signed 
on/bid). 

5 The number of bids/participants is set before bidders can sign 

on/participate. Therefore, the participant starts immediately when the set number 
of bids is entered, as a genuine off-line/non interactive auction. 

The server has, based on number of allowed bids (function of bids per 
participant/participants), created a time simulation string, divided into individual 
10 blocks with enough individual blocks to allow for space between bids (unused 
blocks), i.e. to allow for any bid in the string to win - at the beginning - middle - 
end). This procedure is a total replica/simulation of the "real-time" auction, save for 
the interactive element. I.e. the participants cannot in this auction, react to the 
other participants during the auction. Otherwise the selection criteria for the winner 
1 5 is exactly the same. 

When bids have been made, and all bids have been given in, the auction 
machine will immediately simulate the time, and carry out the auction based on 
bid-input. Thus a winner/Winners is/are selected. 

When this is done, the participants may enter the organizer's home page 
20 and retrieve the auction log and the visualization of the auction. 

Each individual will be able to see his bids on his screen, and how long 
time each bid lasts. Subject to a limited number of bids per player, the whole 
auction may be visualized over a period of 5 minutes. 

Regarding the length of the auction, the actual simulation is instant. 
25 However, a participant will use the time it takes to bid. Total individuality of when 
done. 

Since dependent on a fixed number of bids having been made, the point in 
time when the actual auction is run on the auction-machine is not known. 

This auction may be played at any time, but may have a delay in selection 
30 of winner. 

Since time is simulated, the problem of 1 st bid does not appear. There will 
always be a first bid. Then the auction starts. 
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A bid wins as long as no other bids coming in within a set number of 
seconds. At the outset this time is planned set at 30 seconds. 

The simulation of seconds between bids is done by allocating a number of 
seconds to each block (position where bids are allowed). Since there are more 
5 blocks in a time-string (the total auction time) than bids allowed, there may be 
open spaces/blocks between two bid representing 30 seconds, and thus a winner 
may appear before auction time end. The trick is to estimate number of blocks 
relative to number of bids, to allow for both a winner at the beginning/middle and 
end (last bidder), subject to total bidding strategy. 
10 Such protection may be an issue if a participant can manipulate the auction 

machine before auction starts. When time-simulation/auction winner is calculated, 
this is done off-line, i.e. no jamming/manipulation is then possible from outside 
sources. 

Optional features: 

15 As this auction embodiment is totally non-interactive and off-line with the 

auction machine, the interactive feature of the other auctions is non-existent. It 
may however be provided with extra features to give a semblance of interactivity. 
(See below). 

One or more of the below items should be present in the auction for 
20 attractiveness and entertainment value: 
• Simulated Interactivity 

The auction is totally non-interactive in all phases. However, one may 
create, as earlier mentioned, a semblance of interaction, with pop-up theme during 
individual play, exactly the way as described under "Simulation 2", see below. 
25 • Design 

The purely entertaining features are the background design visualizing the 
action of the participants via theme-stories. The story will be simpler than the "real 
time" version (during the placing of bids), and cannot reflect interactively the action 
on the graphical "bid-board", as bidding is done over a period of (say) 15 minutes. 
30 |t is however, important to give an impression of interactivity or at least 

action. 



WO 99/27476 PCT/NO98/00348 

35 

This cannot be done by interacting with other bidders 1 actions however, as 
this would be misleading (there will always be some participants who have not yet 
placed their bids - thus affecting strategy for an individual participant after 
individual participant made his bid). Thus the theme design must interact with 
5 other parameters than actual bidding. One may bring his individual log from a 
previous auction, to guide current bidding as well as background story. 

Another feature is that a participant may choose from a range of 
background stories, the one to his liking, which gives him/her most excitement, or 
alternatively drop the theme stories altogether to concentrate 100% on the bidding 
10 process. 
• Strategy 

Same as in "real time" embodiment. 

A limited number of participants give high winning chances compared to 
most other game types, thus giving a high attraction value. 
15 Market segmentation: 

1* tier segmentation : Access to PC. 

2 nd tier segmentation : Cost of bids (i.e. covers affluent and average 
segment based on this variable), and limited/no time for playing a "real time" 
auction. 

20 

C) SIMULATION 2 - Non interactive/perceived (partly) interactive, see fig. 10. 

Fig. 10 represents an embodiment that is an intermediate solution in 
relation to what is shown in figs. 8 and 9. The participants really do not engage in 
an interactive auction, but have nevertheless a specified time period, symbolized 
25 by the two clocks, during which to place their bids in time. The "broken" film roll 
symbolizes the non-interactive bidding during the bid period. The machine on the 
right side symbolizes instant calculation of the auction result after expiry of the 
bidding period, and the short "film roll" on the far right is a log that can be fetched 
at any later time. 

30 This type of simulated auction is non-interactive, with unlimited number of 

participants. Participants are signing on/purchasing bids individually up to a pre- 
set starting time, but bidding during an interval of a limited time (bid-time). 
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When number of bids/participants is known (at starting point), the auction 
server makes a time simulation string, divided in individual blocks (simulating an 
auction), with enough individual blocks to allow for space between bids (i.e. allows 
for any bid in the string to win, as there may be gaps between each bid so that 
5 any bid may win - either at the beginning/middle or end). 

The participants are allowed 10/15 minutes to use their bids in the string - 
which may be visualized multi-dimensionally for easy bidding on a coupon. 

When the bids have been entered (within the allowed bid period), the 
auction machine will immediately/instantly simulate the time (auction), and come 
10 up with a winner/winners. 

The auction will be visualized immediately when the winner has been 
"calculated", via a meter showing bid activity on a time axis, with the individuals' 
bids entered. Each individual will see his bids on his screen, and how long each 
bid lasts. Subject to a limited number of bids per participant, the whole auction 
15 may be visualized over a period of approx. 5 minutes no matter how many 
participants are participating. 

The length of the auction is independent of the number of participants/bids. 
Fixed time for bidding (on-line, non-interactive). Total auction time including 
visualization may be approx. 1 5/20 minutes. 
20 A benefit of this auction embodiment is that a participant not having time for 

"Real time" participation (or wanting a second auction, after "real time" play) may 
enter this auction. 

Since time is simulated, the problem of 1 st bid does not appear. There will 
always be a first bid. Then the auction starts. 

25 A bid wins as long as no other bids are coming in within a set number of 

seconds. At the outset this time is planned set at 30 seconds. The simulation of 
seconds between bids, is done by allocating a number of seconds to each block 
(position where bids are allowed). Since there are more blocks in a time-string (the 
total auction time) than bids allowed, there may be open spaces/blocks between 

30 two bids representing 30 seconds, and thus a winner may appear before auction 
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end. The trick is to estimate number of blocks relative to number of bids, to allow 
for both a winner at the beginning/middle and end (last bidder), subject to total 
bidding strategy. 

Jamming/unauthorized acccess - protection 

5 Such protection may be an issue if a participant can manipulate the auction 

machine before auction starts. 

When a time-simulation/auction winner is calculated, this is done off-line, 
i.e. no jamming/manipulation is possible from outside sources. 
Optional features: 
10 All of the three below items will have (be perceived as having) 

entertainment value for the participants and set the auction above other game 
types: 

• Interactivity 

• Design 

15 • Strategy auction (log - analysis of individual strategy compared to other 
participants/winner after auction ends - or alternatively during auction) 

• Interactivity 

The auction is not interactive in the normal sense (like the "real time" 
version), however, this is an auction alternative for individuals not having time for 
20 the fully interactive version Since the auction is played (bids placed) during a pre- 
set period, and the auction is visualized in "amended real time" the participants 
will perceive the auction as if they were participating interactively during the 
viewing/visualization. 

• Design 

25 The purely entertaining features are the background design visualizing the 

action of the participants via theme-stories. The story will be simpler than the "real 
time" version (during the placing of bids), and cannot reflect interactively the action 
on the graphical "bid-board", as bidding is done over a period of (say) 15 minutes. 
It is however, important to give an impression of interactivity or at least 

30 action. This cannot be done by interacting with other bidders 1 actions however, as 
this would be misleading (there will always be some that have not yet placed their 
bids - thus affecting strategy for an individual participant after he has made his 
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bid). Thus the theme design must interact with other parameters than actual 
bidding. One may bring his individual log from a previous auction, to guide current 
bidding as well as background story. 

Another feature is that a participant may choose from a range of 
5 background stories, the one to his liking, which gives him/her most excitement, or 
alternatively drop the theme stories altogether to concentrate 100% on the bidding 
process. 
• Strategy 

Same as in "real time" embodiment 
10 • Pot/winning chances 

The unlimited number of participants gives lower winning chances than the 
"real-time" auction, however, on the other side, the pot may be very much higher. 
Market segmentation: 

1 st tier segmentation : Access to PC. 
15 2 nd tier segmentation : Cost of bids (I.e. covers affluent and average 

segment based on this variable), and limited time for playing. 



LEVELS OF SCREEN ACTIVITIES 

(VISUALIZATION): The visual story on the screen (theme) as experienced by a 
20 participant needs to be created as interactive, with actions interacting on different 
levels with auction activities. It will be basically four levels which should be 
individually interacting as follows, and a fifth "just for fun"; 

• The setting (general theme) 

• The auctioneer 

25 • The general participant population ("competitors" - everyone but you) 

• The individual participant (feedback on individual action) 

• Funny "pop-ups" (sit-com) - (randomly distributed throughout the auction), just 
for fun, as well as a "confusion element" 
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FACTS/INFO TO PARTICIPANTS DURING AUCTION: 

Particularly in a real time computer network auction embodiment, but also 
in simulation embodiments, the following information will be of interest for the 
participants, and any or all of the features listed below should be transmitted to 
5 the participants PC's: 

• Timing of bid-round (Fixed, random or sequential) - It is believed that the 
random alternative is most exciting, where the count-down meter (to winning) 
shifts randomly from 30 sec to 20 sec to 15 sec during the auction. This will 
heighten the excitement, and necessitate higher concentration throughout the 

10 auction. 

• Each bid's individual life 

• Traffic (how many bids entered during a time sequence/period) 

• Number of bids left (total and individual) 

• Number of bids placed (total and individual) 
15 • Total number of bids (total and individual) 

• Number of participants 

• Pot size 

LOG PARAMETERS: The log is intended to be a guide for the participants, 
20 informing them of their actions/ non-actions and how it affects their winning 
chances. The log will also inform them of their strategy compared to 
optimal/winning strategy, and give suggestions for alternative strategies which 
may help them in next auction, hence giving a feeling of winning chances "no 
matter whether I was not winning this time". The auction log will be accessible 
25 after the auction is over. We expect the auction log also to have an independent 
entertainment value, and can be visualized on the participant PC screens. 
The following elements will be (considered to be) included in the log: 

• You are the Winner 

• Time each bid lasted (before competitive bid placed) 
30 • Time all bids lasted 

• How many rounds stayed cool ("wait" position at the end of a round/total 
accumulated rounds) 
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• How many times stayed cool (accumulated) 

• How many times same strategy as others (acting within same "second" as 
others, and how many others 

• How many times different strategy (define "different") 
5 • Optimal strategy vs. your strategy 

• Winners strategy vs. your strategy 

• Alternative winning strategies in this auction (good advice for next game) 

IDEAS FOR THEMES: As example of alternative themes: 
10 • Auction with "Einstein" personifying an auctioneer 

• Auction on a Steamboat on Mississippi (1870'ish) 

• Auction on a castle in Scotland 

• "Indiana Jones" - obstacle course - live/die (Searching for the Holy Grail) 

• Traditional auction (with sit-com pop-ups) 
15 • Casino environment/high society 

• Straight auction coupon (as Lotto), the "no fuzz" version for Simulation auctions 

• Etc. 

SIT-COM/POP-UPS: The sit-coms could be a special, recognizing feature for 
20 the organizer's auctions, (example Gary Larson's "The Far Side") and could also 

be used for advertisement during the auction. The idea would be continuously 

creating new pop-ups. 

The pop-ups confuse the participant as well as provide the auction with 

added entertainment value. They must be so interesting and comic that they 
25 interfere with participant concentration, but makes the auction more fun to 

participate in (as a compensation for loss of concentration - and possibly loss of 

the auction, even). Randomly appearing sit-coms should appear not too often, and 

should appear/disappear in say 5/6 sec. 

The pop-ups can both appear in "real-time", and particularly in the 
30 Simulation versions of the auction, to make those more "interactive" and 

interesting/ entertaining. 
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Fig; 1 1 shows, in a general manner and similar to fig. 1 , the various 
parties/objects that may be involved in an auction system according to the 
invention. Two or more objects may be interconnected in open or closed 
communication that may be analogue or digital. In addition to participant PC-s and 
5 auctioneer servers, which have been dealt with extensively here above, the 
following possibilities shall be mentioned: 

video/automaton auctions may be realized either with a connection via a 
network to an auctioneer server, or the complete auction system may be realized 
inside such an automaton, the auction type then being one with simulated other 
10 participants. (Such a free-standing automaton may also be realized in the form of 
a small e.g. palm-held, apparatus.) 

However, an automaton may of course operate as a terminal in a similar 
manner as a PC. 

One way of conducting an auction in accordance with the invention, is in 
15 connection with a TV or radio show. In such a case, normal TV, text TV or radio 
channels (public or closed-circuit) may be used as one part of the communication 
network, namely for presenting the current real time auction progress for the 
participants, who may e.g. use a telephone network (cellular or pub|ic switched 
network) as the network part for bidding, i.e. sending bid messages to the 
20 auctioneer. Hence, the elements telephone, radio and TV are shown in the 

drawing, along with a telefax which is also a possible interface unit in connection 
with a telephone network. It should also be noted that in a digital television 
network, two-way communication will be possible, hence providing a possibility for 
TV sets with message return with the aid of touch screens or e.gi. hand-held 
25 remote controls. 

Finally, in e.g. a TV show there will usually be an audience and audience 
persons may also take part as auction participants, then receiving an interface unit 
(radio or wire connected to the auctioneer computer) for entering into a bidding 
session. 
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Fig. 12 shows an example of a "bid board" that can be used in connection 
with an "instant" type auction, see fig. 9, and such a bid board can be presented 
on a PC screen or e.g. an automaton. Placing of bids, i.e. marking specific points 
of time, is made in a simple manner by moving to hour, minute and second 

5 positions in the three scales/dials shown, and confirming when a desirable time 
point has been set. When all allowed bids have been placed, the total bid package 
is sent to the auctioneer by using the "SEND" button. One feature that can be 
included, is an "accumulated bid value", showing the sum value of all bids made 
so far at the moment of entering a bid, to give the participant an idea of the 

10 possible winning pot. 



WO 99/27476 



PCT/NO98/00348 



43 

PATENT CLAIMS 
1 . A computerized auction system comprising: 

auction means for processing bids communicated from participants of an 
5 auction, communicating receipts of said bids and status details of said auction to 
said participants, and determining a winner of said participants based on said bids 
received and communicating said winner to said participants; 

bidder means for distinctly communicating to said auction means distinct 
said bids from respective said participants and processing said receipts of said 
10 bids and said status details of said auction communicated from said auction 
means; 

network means for providing communication transmission paths between 
said auction means and said bidder means, information communicated across 
said network means between said auction means and said bidder means being 

15 under at least one of a first transport protocol and a second transport protocol, 

said first transport protocol being more reliable than said second transport protocol 
with respect to insuring that data representative of said information arrives at one 
of said auction means and said bidder means, said second transport protocol 
being faster than said first transport protocol with respect to time elapsed for said 

20 data to be sent across said network means and received by one of said auction 
means and said bidder means, eherein risks associated with said information 
communicated under said second transport protocol include loss of said data 
during transmission across said network means, arrival of said data at one of said 
auction means and said bidder means in an order different from a temporal order 

25 in which said data were sent from respective one of said bidder means and said 
auction means, and duplicates of said data arriving at one of said auction means 
and said bidder means, said risks being an aspect of said auction in respect of 
said determining said winner of said participants. 

30 2. The auction system according to claim 1, wherein said bids are 

communicated from said bidder means to said auction means under said second 
transport protocol. 
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3. The auction system according to claim 1 , wherein said auction means 
comprises auctioneer means for processing said bids communicated from said 
bidder means and communicating said receipts of said bids and said status details 

5 of said auction to said bidder means, said auctioneer means communicating with 
said bidder means under said second transport protocol. 

4. The auction system according to claim 3 f wherein said auction system 
comprises administrative means for processing accounts of said participants and 

10 processing information related to said auction apart from information 
communicated between said auctioneer means and said bidder means. 

5. The auction system according to claim 4, wherein said administrative 
means further comprises means for processing content in a form of World Wide 

15 Web pages communicated to and from said bidder means. 

6. The auction system according to claim 4, wherein said auction means 
includes auction support means for prompting said auction means to begin said 
auction, said auction support means communicating with said administrative 

20 means on a secure communications channel over a transmission path that is one 
of outside said network means and through said network means. 

7. The auction system according to claim 6, wherein said auction support 
means further comprises means for storing results of said auction. 

25 

8. The auction system according to claim 6, wherein said auctioneer means 
and said auction support means together comprise a first computer network server 
coupled to said network means, and said administrative means comprises a 
second computer network server coupled to said network means. 

30 
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9. The auction system according to claim 1, wherein said network means 
comprises at least one of a telephone network, a public mail network, a telefax 
network, a local area network, and the Internet, said first transport protocol 
comprises a Transport Control Protocol/Internet Protocol (TCP/IP), and said 

5 second transport protocol comprises a User Datagram Protocol (UDP). 

10. The auction system according to claim 5, wherein said network means 
comprises the Internet, said first transport protocol comprises a Transport Control 
Protocol/Internet Protocol (TCP/IP), and said second transport protocol comprises 

10 a User" Datagram Protocol (UDP). 

1 1 . The auction system according to claim 10, wherein said auctioneer means 
communicates with said bidder means under said UDP t said administrative means 
communicates with said bidder means under said TCP/IP, and said auction 

15 support means communicates with said administrative means under a secure 
sockets layer (SSL). 

12. The auction system according to claim 3, wherein said bidder means 
communicate with said auctioneer means under auction protocols layered on top 

20 of one of said first and second transport protocols. 

13. The auction system according to claim 12, wherein said auction protocols 
comprise auction administration and bidding protocols. 

25 14. The auction system according to claim 13, wherein said auction 
administration protocols include parameters comprising names of said 
participants, identification of access communication ports to said auctioneer 
means by said bidder means for respective said participants, identification of said 
winner of said participants, time reference for said auction, time when said auction 

30 is to start, time when said auction is to be finished, time when a current one of 
said bids becomes a final bid, number of accumulated said bids at any one time, 
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number of said bids a particular one of said participants has left to submit in said 
auction, and how long a particular one of said bids must remain highest of said 
bids to become a winning one of said bids. 



5 15. The auction system according to claim 13, wherein said bidding protocols 
include parameters comprising a value for each of said bids, counts of messages 
received by said auctioneer means from said bidder means for each of said 
participants, notions of time of said auction by each of said bidder means, 
identification of winner of said participants, time when said auction started, time 
10 when said auction is over and a current one of said bids becomes a final bid, 
number of said bids communicated to said auctioneer means at any one time, 
number of bids each of said participants has left, how long one of said bids must 
survive to win in said auction, and number of said participants. 

15 16. A computer network auction system server comprising: 

means for processing bids communicated from participants of an auction 
across a computer network, 

means for communicating information across said computer network to said 
participants in response to said bids communicated from said participants, 
20 means for determining a winner of said participants based on said bids 

received across said computer network; 

means for communicating across said computer network said winner to 
said participants; 

means for a first transport protocol under which said means for 
25 communicating information and said winner are carried out; and 

means for a second transport protocol under which said bids are 
communicated across said computer network from said participants, 
communications under said first transport protocol being more reliable than under 
said second transport protocol with respect to said communications arriving at 
30 their destination, communications under said second transport protocol being 
faster than under said first transport protocol in respect of time from initially 
transmitting said communications to arrival of said communications at an intended 
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destination, wherein risks associated with communicating under said second 
transport protocol include loss of said bids during transmission across said 
computer network, arrival of said bids from different ones of said participants 
being in an order different from a temporal order in which said bids were sent from 
5 respective ones of said participants, and duplicates of at least one of said bids 
arriving at an intended destination, said risks being an aspect of said auction in 
respect of said means for determining said winner of said participants. 

17. The computer network auction server according to claim 16, further 

10 comprising administrative means for processing accounts of said participants. 

18. The computer network auction server according to claim 17, wherein said 
administrative means further comprises means for processing content in a form of 
World Wide Web pages communicated to and from said bidder means. 

15 

19. The computer network auction server according to claim 16, wherein said 
first transport protocol comprises a Transport Control Protocol/Internet Protocol 
(TCP/IP), and said second transport protocol comprises a User Datagram 
Protocol (UDP). 

20 

20. The computer network auction server according to claim 16, wherein said 
bids are communicated from said participants under auction protocols layered on 
top of one of said first and second transport protocols. 

25 21 . The computer network auction server according to claim 20, wherein said 
auction protocols comprise auction administration and bidding protocols. 

22. The computer network auction server according to claim 21 , wherein said 
auction administration includes parameters comprising names of said participants, 
30 identification of access communication ports to said auctioneer means by said 
bidder means for respective said participants, identification of said winner of said 
participants, time reference for said auction, time when said auction is to start, 
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time when said, auction is to be finished, time when a current one of said bids 
becomes a final bid, number of accumulated said bids at any one time, number of 
said bids a particular one of said participants has left to submit in said auction, and 
how long a particular one of said bids must remain highest of said bids to become 
5 a winning one of said bids. 



23. The computer network auction server according to claim 13, wherein said 
bidding protocols include parameters comprising a value for each of said bids, 
counts of messages received by said auctioneer means from said bidder means 

10 for each of said participants, notions of time of said auction by each of said bidder 
means, identification of winner of said participants, time when said auction started, 
time when said auction is over and a current one of said bids becomes a final bid, 
number of said bids communicated to said auctioneer means at any one time, 
number of bids each of said participants has left, how long one of said bids must 

15 survive to win in said auction, and number of said participants. 

24. A method for implementing an auction system on a communication 
network, said method comprising: 

communicating bids by input computer equipment of respective participants 
20 of an auction across a network to auction computer equipment; 

processing received said bids by said auction computer equipment; 
providing by said auction computer equipment across said network receipts 
of said bids to said input computer equipment; 

determining by said auction computer equipment a winner of said 
25 participants based on said bids received from said input computer equipment; and 
communicating by said auction computer equipment to said input 
computer equipment said winner of said participants; 

providing first and second transport protocols under which 
communications between said auction computer equipment and said input 
30 computer equipment are carried out, said first transport protocol being more 

reliable than said second transport protocol with respect to said communications 
arriving at an intended destination, said second transport protocol being faster 
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than said first transport protocol with respect to time elapsed for said 
communications to be sent across said network and received by at least one of 
said input computer equipment and said auction computer equipment, wherein 
risks associated with said communications under said second transport protocol 
5 include loss of said communications in said network, arrival of said 

communications at one of said auction computer equipment and said input 
computer equipment in an order different from a temporal order in which said 
communications were sent from respective one of said input computer equipment 
and auction computer equipment, and duplicates of said communications arriving 
10 at one of said auction computer equipment and said input computer equipment, 
said risks being an aspect of said auction in respect of said determining said 
winner of said participants. 

25. The method according to claim 24, further comprising processing accounts 
1 5 of said participants. 

26. The method according to claim 24, further comprising storing results of 
said auction. 

20 27. The method according to claim 24, wherein said network comprises one of 
a public mail network, a telephone network, a telefax network, and a computer 
network. 

28. The method according to claim 24, wherein said network comprises the 
25 Internet, said first transport protocol comprises a Transport Control 

Protocol/Internet Protocol (TCP/IP), and said second transport protocol comprises 
a User Datagram Protocol (UDP). 

29. The method according to claim 24, further comprising carrying out 

30 communications related to said bids between said auction computer equipment 
and said input computer equipment under auction protocols layered on top of one 
of said first and second transport protocols. 
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30. The method according to claim 29, wherein said auction protocols comprise 
auction administration and bidding protocols. 

5 31. The method according to claim 30, wherein said auction administration 
protocols include parameters comprising names of said participants, identification 
of access communication ports to said auctioneer means by said bidder means for 
respective said participants, identification of said winner of said participants, time 
reference for said auction, time when said auction is to start, time when said 
10 auction is to be finished, time when a current one of said bids becomes a final bid, 
number of accumulated said bids at any one time, number of said bids a particular 
one of said participants has left to submit in said auction, and how long a 
particular one of said bids must remain highest of said bids to become a winning 
one of said bids. 

15 

32. The method according to claim 30, wherein said bidding protocols include 
parameters comprising a value for each of said bids, counts of messages received 
by said auctioneer means from said bidder means for each of said participants, 
notions of time of said auction by each of said bidder means, identification of 

20 winner of said participants, time when said auction started, time when said auction 
is over and a current one of said bids becomes a final bid, number of said bids 
communicated to said auctioneer means at any one time, number of bids each of 
said participants has left, how long one of said bids must survive to win in said 
auction, and number of said participants. 

25 

33. A method for implementing an auction on a computer network server, said 
method comprising: 

processing bids communicated from participants of an auction across a 
computer network, 

30 communicating information across said computer network to said 

participants in response to said bids communicated from said participants, 
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determining a winner of said participants based on said bids received 
across said computer network; 

communicating across said computer network said winner to said 
participants; 

5 communicating across said computer network under one of a first transport 

protocol and a second transport protocol, arrival of communications at an intended 
destination being more reliable but slower under said first transport protocol than 
under said second transport protocol, risk of communications being lost, delayed 
and duplicated under said second transport protocol being an aspect of said 
10 auction in respect of determining said winner of said participants. 

34. The method according to claim 33, wherein said first transport protocol 
comprises a Transport Control Protocol/Internet Protocol (TCP/IP), and said 
second transport protocol comprises a User Datagram Protocol (UDP). 

15 

35. The method according to claim 33, wherein said bids are communicated 
from said participants under auction protocols layered on top of one of said first 
and second transport protocols. 



20 36. An auction system based upon submittal of stake-supported bids from 
auction participants within pre-established time limits, said system possibly 
comprising a communication network for communication between an auctioneer 
and the participants, said auction system comprising 

- interface means adapted for presenting bids from the participants, 
25 - a detector means for detecting bids submitted from each participant, 

- a real or simulated clock situated with the auctioneer for marking the start 
and end times for an auction, recording running auction time as well as time points 
for bid detection in said-detector means, and 

- a decision means for deciding on an auction result, the auction result being a 
30 function of the bid time points. 
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37. The auction system of claim 36, wherein said decision means is adapted to 
test whether a predetermined time period, or a time period variable according to 
predetermined rules, has passed after the last detected bid without detection of a 
new incoming bid, and if this is the case, to identify the participant with the last 

5 detected bid as an auction winner, and if this is not the case during the total 

auction duration, to identify the participant having submitted the last bid before the 
auction end time, as a winner. 

38. The auction system of claim 36, wherein said interface means are 
10 computer terminals attached to a real time data-transmitting communication 

network, possibly via modem, and wherein the auctioneer is attached to the same 
network by means of a computer terminal in a similar manner. 

39. The auction system of claim 38, wherein the auctioneer clock, the detector 
15 means and the decision means are comprised in an auctioneer computer adapted 

to manage an auction in accordance with programmed auction algorithms. 

40. The auction system of claim 39, wherein the auctioneer computer 
algorithms are adapted to manage bids submitted in real time from the participants 

20 during the course of the auction, and wherein said computer is adapted for 

possible correction due to transmission delay from the computer terminals of the 
participants. 

41 . The auction system of claims 37 and 40, wherein one of said auctioneer 
25 computer algorithms is an algorithm for varying the length of said time period as 

function of elapsed auction time or current bid submittal rate from all participants. 

42. The auction system of claim 40, wherein the participant computer terminals 
and also the communication network are adapted for transmission of real time 

30 information from the auctioneer computer, in order to present to each participant 
the running auction progress and activity. 
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43. The auction system of claim 39, wherein the auctioneer computer 
algorithms are adapted to manage bids submitted in a group from each participant 
within a fixed point of time, so that when this point of time has passed, said 
computer can immediately simulate the total course of the auction. 

5 

44. The auction system of claim 43, in which the total number of bids during the 
auction is predetermined, said auctioneer computer algorithms being adapted to 
manage bids submitted from each participant at the same time as the participant 
makes entry for the auction/pays the bids. 

10 

45. The auction system of claim 43, in which no limit is set for the total number 
of bids during the auction, said auctioneer computer algorithms being adapted to 
manage a) auction entry/payment of bids from each respective participant within a 
predetermined point of time, b) thereafter calculating the total auction time, i.e. the 

15 time span from start to end time, c) establishing a time limit for submittal of 
grouped bid times, from each respective participant, and (d) subsequent to 
reception of bids from the participants and expiry of said time limit, simulation of 
the total course of the auction. 



20 46. The auction system of any of claims 43-45, wherein said auctioneer 

computer, participant computer terminals and communication network are adapted 
for transmission of information about the simulated course of the auction to each 
respective participant, possibly in the form of a screen presentation of the auction 
course in a real or transformed time scale. 

25 

47. The auction system of claim 42 or claim 46, wherein said auctioneer 
computer is also adapted to transmit, in accordance with special programming, 
side information to the participant computer terminals, (a) said side information 
being controlled during real time or simulated auction progress by the auctioneer 
30 clock and possibly by the running auction development, for initiating picture/sound 
presentation or short film of a type which is auction related, entertaining or 
distracting, next to or "behind" the auction information, in order to increase the 
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auction attraction, and (b) said side information comprising, during phases with 
entry/payment/pre-bidding, animations containing entertainment or auction related 
information or possibly advertising. 

48. The auction system of claim 39, wherein said auctioneer computer 
comprises a memory for storing a total auction course, so that a participant may 
have data concerning said auction course presented in his computer terminal 
automatically or on request after a finished auction. 

49. The auction system of claim 36, where at least one participant is a genuine 
participant and a plurality of participants is a number of simulated participants, the 
system further comprising auctioneer random generator means controlling said 
number of and bidding times for simulated participants in accordance with 
predetermined random generator algorithms, said algorithms containing 
parameters adjustable so as to tune auction winning probability into a range that is 
compatible with national law. 

50. The auction system of claim 36 or 37, wherein 

- part of said communication network is any of a public switched telephone 
network, a cellular network, a computer network and a reverse TV channel 
network, 

- said interface means are any of telephones, cellular phones, telefax units, 
computer terminals, and TV sets having two-way communication capabilities, 

- the auctioneer broadcasting any of a radio program, a TV program and a Text 
TV program via another part of said communication network constituted by any of 
a public radio channel, a TV channel and a closed-circuit network, in which 
radio/TV/Text TV program real time information is transmitted regarding auction 
progress. 
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51 . The auction system of claim 36, wherein the interface means are coupons 
to be completed by each participant and sent to the auctioneer, a coupon 
containing information about the desired bid time points for the participant in 
question within a pre-established time frame, and with a number of bids fixed 
5 according to rule and according to stake, said detector means is a coupon reader 
unit, said decision means is a preprogrammed computer attached to said coupon 
reader unit, and said clock is a simulated clock according to which the bids from 
the participants are ordered chronologically, said communication network being a 
public mail network, a telephone network, a telefax network or a computer 
10 network. 



52. A method for an auction based upon submittal of stake-supported bids 
from auction participants within pre-established time limits, said auction 
comprising the steps of: 
15 presenting to an auctioneer bids from the participants via at least 

interface means, 

detecting by auctioneer bid detector means bids submitted from any 
participant, 

using a real or simulated clock situated with said auctioneer for marking 
20 start and end times for said auction, and for recording running auction time as well 
as time points for bid detection by said auctioneer bid detector means, and 
deciding on an auction result by an auctioneer decision means, the 
auction result being a function of the bid time points. 

25 53. The auction method of claim 52, further comprising testing whether a 

predetermined time period, or a time period variable according to predetermined 
rules, has passed after the last detected bid without detection of a new incoming 
bid, and if this is the case, identifying the participant with the last detected bid as 
an auction winner, and if this is not the case during the total auction duration, 

30 identifying the participant having submitted the last bid before the auction end 
time, as a winner. 
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